What is Resource-Aware Verification?

Exhaustive verification methods such as model-checking suffer from the well-known state-explosion problem: the set of states is too large to explore exhaustively in reasonable amounts of time and space (memory). But model-checkers are often plagued with another problem, which makes state-explosion even worse: the disk-swapping problem. The latter problem manifests itself when the model-checker fills up the main memory of the computer it runs on, but without exhausting the virtual memory address space. At this point disk-swapping occurs, which is very slow and essentially makes the search stagnate: the rate of explored states (number of visited states per second) becomes practically zero. The disk-swapping wall is usually hit pretty quickly. For example, using a model-checker that can explore 105 new states per second, on a model that requires 1000 bytes to represent each state, consumes memory at a rate of approximately 100 MB/sec. This means that a main memory of size 8 GB can be filled in about 2 minutes. Exploration rates in the order of 105 states per second are not unusual today, for an advanced model-checker such as Spin [1]. Ideally, we would like to have a verification method that scales well with resources. Informally, this could mean that the more time or the more memory we have available, “the more we can verify”. In turn, “how much we verify” can be quantified as “how many distinct reachable states we explore”. Ideally, we would like to have a verification tool that, say, if we let it run for 2 hours we would expect it to explore twice as many states than if we let it run for 1 hour (or it will explore the entire state space). This is an ideal goal, of course, which is hard, if not impossible, to reach. On the other hand, a method that after n hours explores only % more states than after 5 minutes is clearly not scalable with resources.